Preserve MongoDB listener container startup behavior - #1118
Conversation
|
Hi @fregulha - I believe this is tackling #1084, not #1085. I also opened #1119 around the same time as you to tackle the My implementation covers a broader set of @bean return patterns, including direct construction, locally-declared containers, multiple and nested return paths, locally assigned fields, same-named variables in separate scopes, reassignment, and simple one-hop same-class helper methods. It evaluates each return path independently and tracks variables by It also preserves explicit For cases where the container provenance cannot be established safely — such as deeper helper chains, cross-class calls, or fields without a locally-visible assignment — it leaves the return unchanged and adds a targeted diagnostic for manual review. It looks like our PRs overlap substantially, so it would probably make sense to align on which implementation to take forward. |
2 participants
What's changed?
PreserveDefaultMessageListenerContainerStartup, which preserves manual startup behavior for Spring-managedDefaultMessageListenerContainerbeans during migration to Spring Data MongoDB 5.0.setAutoStartup(false)when the transformation can be performed safely.setAutoStartup(...)configurations remain unchanged.UpgradeSpringDataMongoDb_5_0.What's your motivation?
Spring Data MongoDB 5.0 automatically starts
DefaultMessageListenerContainerbeans. Applications that previously started these containers manually could experience an unintended behavior change after upgrading.This recipe preserves the previous behavior by explicitly disabling automatic startup where appropriate.
Anything in particular you'd like reviewers to focus on?
The detection of supported
@Beanfactory methods, preservation of existing explicit startup configuration, and manual-review handling for configurations that cannot be transformed safely.Anyone you would like to review specifically?
No specific reviewer.
Have you considered any alternatives or workarounds?
Users could identify and update each listener container manually, but including this transformation in the MongoDB 5.0 migration recipe makes the upgrade safer and repeatable.
Any additional context
The dedicated recipe and composite MongoDB 5.0 migration test suites pass successfully. Recipe marketplace CSV and license validations also pass.
The complete test suite was attempted on Windows. Six tests outside the affected packages failed: three import expectation tests in
GetErrorAttributesTestand three Unix path-separator assertions inRenameLogbackToLogbackSpringTest.Checklist